Telecommunication service providers are constantly looking for new ways to deliver personalized, differentiated, real-time multimedia services, such as collaborative meetings and subscriber-initiated service management. By incorporating Voice over Internet Protocol (“IP”) capabilities, new features can be provided to users of existing communications networks. Furthermore, such technologies allow for the integration of voice, video, and data capabilities over an IP network using a single packet infrastructure.
One emerging protocol for Voice over IP applications is Session Initiation Protocol (“SIP”). Currently, SIP is a draft protocol published by the Internet Engineering Task Force (“IETF”), which is the body responsible for administering and developing the mechanisms that comprise the Internet. A formal definition of SIP can be found in IETF's Request For Comment (“RFC”) 2543—SIP: Session Initiation Protocol. This document may be found at http://www.faqs.org/rfcs and is incorporated by reference its entirety into this application.
SIP is a signaling protocol used for establishing sessions in an IP network. It is an ASCII-based, application layer control protocol that can be used to establish, maintain, and terminate sessions between two or more end points. A session could be a simple two-way telephone call or it could be a collaborative multi-media conference session. SIP, however, does not control the actual session. It just provides the signaling so that a session can be established. SIP's basic architecture is client/server in nature. There are two main components with a SIP network: the SIP user agent and the SIP network server. The user agent is effectively the “endpoint” or end system component for the session or call. The SIP server is the network device that handles signaling associated with multiple calls. Either the SIP server or the end point can function as the client or server, depending on which component is making the request (i.e., the client) and which component is providing a response (i.e., the server).
SIP is based on a request-response philosophy. As such, it closely resembles Hypertext Transfer Protocol (“HTTP”) and Simple Mail Transfer Protocol (“SMTP”) which are widely used throughout the Internet. Users in a SIP network are identified by unique SIP addresses. A SIP address is similar to an e-mail address and is in the format of sip:userID@network.com. As will be discussed in detail below, users register with a registrar server using their assigned SIP addresses. When a caller initiates a call, a SIP request is sent to a SIP server. The request includes the address of the caller (in the From header field) and the address of the intended called user (in the To header field). If the called user had previously registered with the network, the SIP server knows where to direct the message. The called user may then respond to the server, which forwards the response to the caller. After acknowledgements of both parties, a session may then be established between the caller and the called user.
Although the overhead of a text-based signaling protocol, such as SIP, has relatively low overhead, there are problems associated with the size of the messages in relation to call setup time. In order to achieve a call setup time in a low bandwidth SIP network that is on par with other technologies, or to reduce message sizes on any network, compression must be performed.
Well known compression techniques, such as ROGER, have been developed as possible compression solutions. Such techniques provide a method for compressing the entire SIP message over the life of the SIP signaling session. These techniques have significantly reduced the amount of bandwidth required for setting up a session, which in turn, have reduced the call setup interval.
In order to use compression techniques, such as ROGER, however a means of compression negotiation must be utilized. What is needed, therefore, is a system and method of compression negotiation during a SIP signaling session.